^7 /#/**• 

3/933 / 

P-31 

Security for Safety Critical 
Space Borne Systems 


(NASA-CR-187656 
CRITICAL SPACE 
37 p 


) security fur 

PQRNE SYSTEMS 


SAFETY 
(Sof tech) 
CSCL 


098 


G3/ol 


N9 I- i 390 d 


Unci as 
0319231 


S. LeGrand 

SofTech, Inc. 


December 31, 1987 

Cooperative Agreement NCC 9-16 
Research Activity No. SEJ2 



Research Institute for Computing and Information Systems 
University of Houston - Clear Lake 



TECHNICAL REPORT 




The 
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Concept 


The University of Houston-Clear Lake established the Research Institute for 
Computing and Information systems in 1986 to encourage NASA Johnson Space 
Center and local industry to actively support research in the computing and 
information sciences. As part of this endeavor, UK-Clear Lake proposed a 
partnership with JSC to jointly define and manage an integrated program of research 
in advanced data processing technology neededjor JSC’s main missions, including 
administrative, engineering and science responsibilities. JSC agreed and entered into 
a three-year cooperative agreement with UH-Clear Lake beginning in May, 1 986, to 
jointly plan and execute such research through RICIS. Additionally, under 
Cooperative Agreement NCC 9-16, computing and educational facilities are shared 
by the two institutions to conduct the research. 

The mission of RICIS is to conduct, coordinate and disseminate research on 
computing and information systems among researchers, sponsors and users from 
UH-Clear Lake, NASA/JSC, and other research organizations. Within UH-Clear 
Lake, the mission is being implemented through interdisciplinary involvement of 
faculty and students from each of the four schools: Business, Education, Human 
Sciences and Humanities, and Natural and Applied Sciences. 

Other research organizations are involvedvia the ‘’gateway” concept. UH-Clear 
Lake establishes relationships with other universities and research organizations, 
having common research interests, to provide additional sources of expertise to 
conduct needed research. 

A major role of RICLS is to find the best match of sponsors, researchers and 
research objectives to advance knowledge in the computing and information 
sciences. Working jointly with NASA/JSC, RICIS advises on research ne eds, 
recommends principals for conducting the research, provides technical and 
administrative support to coordinate the research, and integrates technical results 
into the cooperative goals of UH-Clear Lake and NAS A/ JSC. 
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Abstract 


The Space Station contains safety critical computer software components 
in systems that can affect life and vital property. These components 
require a multilevel secure system that provides dynamic access control of 
the data and processes involved. A study is under way to define 
requirements for a security model providing access control through level B3 
of the Orange Book. The model will be prototyped at NASA/ Johnson Space 
Center. 5hi» paper'"»ill sumnarize those requirements 


Introduction 

The Tri-Service Software Systems Safety Working Group composed the following 
definition: (3] 

Software systems safety is the optimization of systems safety in the 
design, development, use and maintenance of software systems and their 
integration with safety critical hardware systems in an operational 
environment . 

At about the same time, an independent task force led by the Software 
Engineering Research Center (SERC) at the University of Houston at Clear 
Lake (UH-CL) proposed the following definition for use in the research for 
the Space Station Program: 

Safety critical computer software components are defined as computer 
software components (processes, functions, values or program states) whose 
inadvertent occurrence, failure to occur when required, occurrence out of 
sequence, occurrence in combination with other functions or erroneous value 
can result in a hazard or loss of system predictability or control. 

Software can be used in the following ways to safely control a system: 

Autonomous control 

Control of potentially hazardous hardware or system components 
Management of information requiring immediate operator action 
Management of information with which an operator or another 
system makes critical decisions. 
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The Space Station is one of the most complex systems yet undertaken. This 
increases the risk of a combination of faults that individually may not be a 
problem, but combined can cause a serious threat. Safety planning must be 
incorporated into the system development effort from the beginning. This 
allows technical safety mechanisms to complement and augment rather than 
supplant the system design. 

An integral part of this safety is security. Control must be left in the 
domain of the security staff and the trusted computer system. It 3hould 
never be available to the hacker who inadvertently causes damage, the 
terrorist who maliciously seeks to cause destruction, or a disgruntled 
former staff member who leaves with potentially dangerous knowledge. 
Furthermore, software domains should be protected against run away program 
components in another domain and should be recoverable at higher layers 
within their own domain. 

A special multilevel security model must be developed and prototyped that 
will fill the safety requirements of the entire Space Station system with 
its ground, on-orbit and co-orbit subsystems. 

Standards Used 

The following standards are recommended for developing a security prototype 
for Space Station multilevel security. 

OSI Communication Model (8] 

The Open Systems Interconnection provides standards for the exchange of 
information among systems that are "open" to another for this purpose by 
virtue of their mutual use of the applicable standards. A system is a set 
of one or more computers, associated software, peripherals, terminals, human 
operators, physical processes, information transfer means, etc., that forms 
an autonomous whole capable of performing information processing and/or 
information transfer. 

OSI is concerned with the exchange of information between open systems and 
not the internal functioning of each individual open system. The objective 
of OSI \s to define a set of standards to enable open systems to cooperate . 
It uses a layered architecture for operations such as intersystem 
connections, transmission of data and error functions. The OSI model is 
mandated for the design of a network operating system for the Space Station 
Data Management System. {4] 

CAIS-A System Interface Model [21] 

MIL-STD 1838-A, "CAIS-A", provides specifications for a set of Ada packages 
with their intended semantics, which together form the set of common 
interfaces for Ada Programming Support Environments (APSEs) . This set of 
interfaces is known as the Common APSE Interface Set (CAIS) . This interface 
is designed to promote the source-level portability of Ada programs, 
particularly Ada software development tools. The CAIS Model is found in the 
specification for the Space Station Data Management System (DMS) . [4] 

The goal of the CAIS is to promote interoperability and transportability of 
Ada software across DoD APSEs. Interoperability is defined as the ability 
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of APSEs to exchange database objects and their relationships in forms 
usable by tools and user programs without conversion. The DMS 
Specifications call for interoperability of information and database 
components. Transportability of an APSE tool is defined as the ability of 
the tool to be installed on a different Kernel APSE (KAPSE) ; the tool must 
perform with the 3ame functionality in both APSEs. 

The CAIS Model has entities called objects shown as hierarchical nodes on a 
directed graph. The contents, relationships and attributes of nodes are 
defined as well as attributes of the relationships. 

The Orange Book Level B3 Security Requirements [5] 

The DoO Trusted Computer System Evaluation Criteria, commonly called the 
"Orange Book", provides a metric with which to evaluate the degree of trust 
that can be placed in computer systems for the secure processing of 
classified and other sensitive information. It designates two types of 
privileged access: discretionary and mandatory. Discretionary access 
control limits authorized access of objects to named individuals or groups. 
Mandatory security protection involves a comparison of the individual's 
clearance or authorization for the information and the classification or 
sensitivity designation of the information being sought. 

A Level B3 trusted computer base (TCB) involves both discretionary and 
mandatory access control. It must satisfy the reference monitor 
requirements that it mediate all access of subjects to objects, be tamper 
proof and be small enough to be subjected to analysis and tests. A security 
administrator is supported, audit mechanisms are expanded to signal 
security-relevant events, and system recovery procedures are required. The 
access controls are said to be dynamic, since they are administered at run 
time rather than at compile time. 

The Trusted Network Interpretation of the Trusted Computer System Evaluation 
Criteria (TNI) [ t>] 

The Trusted Network Interpretation of the Trusted Computer System Evaluation 
Criteria (TNI) provides a basis for the evaluation of effectiveness of 
security controls built into networks and network component products. The 
specific security feature, the assurance requirements, and the rating 
structure of the Trusted Computer System Evaluation Criteria are extended to 
networks in part 1. In part 2, there is a description of a number of 
additional security services that arise in conjunction with networks. 

The Clear Lake Model for Dynamic Multilevel Security (9) 

This model was first presented at the AIAA/ ACM/NASA/ IEEE Computers in 
Aerospace V Conference, October, 1985. It was developed in a program now 
called the Software Engineering Research Center at University of Houston at 
Clear Lake and sponsored by NASA Headquarters. The Director is Dr. Charles 
McKay, who spawned most of the concepts. The model complies with the 
philosophies of the Orange Book, TNI, OSI and CAIS-A standards. It contains 
attributes about the subjects and objects used in the above standards. The 
model emphasizes developing and sustaining integrity of mission and safety 
critical components in the target environment rather than the protection of 
classified data. 
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Estimated Requirements for Proof-of-Concept Prototype 


These requirements are based on the Clear Lake Model and reflect current 
Space Station design and current versions of the above standards. 

Major SSP Data Management System (DMS) Requirements [4] 

The following is a sample of capabilities mentioned in the SSP Definition 
and Design Requirements Section 2.3.4 on the Data Management System that 
present a challenge to security in this large complex system. This is 
especially true in flight safety critical subsystems. There is a question 

as to how to verify the authority in each case. 

Override capability of automatic systems is required for 
authorized onboard and ground crews. 

A User Interface Executive must keep track of which user is 
linked to which application tool. 

A User Interface Language Interpreter must validate that the 
user has access to processes and files. 

A User Interface Data Base must contain user profiles. 

Performance and trend data is to be displayed to those 
authorized. 

Payload interfaces are to be monitored by those authorized. 

Authorized emergency priority messages must be forwarded. 

Error performance must be user selectable. 

Constraint checking is required. 

Command differentiation is to be suitable for managing 

operations and protect the system from inadvertent and 
unauthorized payload operations. 

Potentially hazardous commands shall be identified. 

Command, communications and data interfaces shall be 
permitted for user operations facility to payload. 

Onboard computational resources shall be provided to host 
authorized customer-provided software. 

Authorized customers shall be allowed to employ data privacy 
mechanisms . 

Privacy must be assured for scientific or user-proprietary 
data. 

Customers must be able to exchange data subject to privacy 
constraints. 

Authorized access is required to onboard planning and 
operational support data with change notation/notifi- 
cation/approval capabilities built in. 

Authorized crew or ground personnel shall be able to modify 
DMS applications software. 

Controlled exchange of data between onboard payloads must be 
offered. 

Protected onboard mass storage capability for customer use 

must be provided. 

Report of transmission status for authorized customer data 

transfers must be supported. 
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The customer must be kept informed on the status of the part 
of the end-to-end onboard network which he is using. 

The transparent transmission, reception, processing, 

controlling, storage and distribution of operational 
data and commands must be supported but also maintained 
by those authorized. 

Caution and warning systems must be managed station-wide and 

interoperable between international modules and maintained 
by those authorized. 

The DMS Systems Manager must interact with the Space 
Station Information System (SSIS) Network Integration 
Manager for security management. 

Local and remote access to onboard DMS 

databases must be consistent with security and privacy practices. 

Authorized onboard processes must be able to obtain or 

clear a global name with the SSIS naming authority. 

Multiple, concurrent, authorized access to onboard data 
shall be provided without interference. 

Restricted views of the database must be offered to the users. 

Structures are to be provided that allow the user to build 

his own checks and control processes for security. 

An emergency mode fix to operational software or data tables 

may be installed onboard with less comprehensive control. 

Major Orange Book Requirements 

The Trusted Computer Evaluation Criteria ("Orange Book") lists the following 
requirements for level B3 security domain for a trusted computer base (TCB) 
that compliment the DMS software specification: 

Discretionary access control shall be to define and control 
access between named users and named objects. . 

Mandatory access control shall consist of hierarchical 

classification levels and non-hierarchical categories. 

Sensitivity labels shall be associated with each system 
resource. 

A subject can read an object at an equal or less security 
level . 

A subject can write to an object at an equal or more security 
level. 

Storage objects shall be purged before reuse. 

The security level of each communication channel shall be 
maintained and audited. 

All human readable output must be marked at the top and 
bottom of the display. 

Terminal users must be immediately notified of a change in 
security level of their associated objects. 

Subjects must be identified before performing any actions. 

Authentication data must be protected. 

Individual users must be uniquely identified. 

Interface between the TCB and user must be by a trusted path. 

There must be an audit trail of access to all objects. 

Accumulation of event that may indicate an imminent violation 
of security policy must be monitored. 
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Immediate notification must be made when security thresholds 
are exceeded. 

The domain of the TCB shall be established for its own 
execution and must be protected from interference. 

The design of the TCB must incorporate significant use of 
layering, abstraction and data hiding. 

The security system must be periodically validated. 

A Security Administrator must be identified and his actions 
be auditable. 

Formal and informal models of security policy must be 
maintained. 

A configuration management plan must be maintained. 

A user's guide must be established and maintained. 

A design document must be maintained that describes the 
interfaces of the TCB. 

Major Requirements: Clear Lake Model for Dynamic Multilevel Security 

The Clear Lake Model is based on LeGrand's access control model for a 
distributed, CAIS-conforming system [9]. It has features that answer the 
requirements of the DMS Specifications and the Orange Book requirements. It 
also complies with the Clear Lake Model for a Network Operating System. 
This system uses Network Application Services, Network Information Services 
and Network Communication Services which share a common interface and a 
common approach to Network Configuration Management Services.. Each set of 
services has agents or managers that act on behalf of subjects or control 
aspects of objects. 

Subject and object nodes, as used in the CAIS Model, would have attributes 
that comply with the ISO Reference Model, Orange Book and TNI. Subjects 
having physical capability and security privileges access objects through 
object managers. The subject attributes would be sent with the request to 
access an object. The object attributes would be located with a description 
of the object, and the object manager in the object's subsystem would 
provide access after making appropriate comparisons. 

Attributes of the subject would be provided by the subject's application 
software and by the access manager in the subject's subsystem. The 
subject's application software would provide the following: 

User/User class/Access Identification (ID) recognizable 
throughout the distributed system. 

Logical Reference meaningful to the user and not necessarily 
an ID unique throughout the system. 

Intent to be compared to the intent under the object's 
attributes. 

Object Type where each object will be typed just as Ada 

elements are typed (record, directory, editor, tape drive, etc.) 

Requested Priority 

Password as required. 
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The access manager in the subject's subsystem verifies the input and 
provides the following: 

Subject' 3 clearance level. 

Subject's subsystem location and device. 

Unique ID of Parent Thread-of-Control 

Unique Transaction ID 

Unique object ID. 

Current roles: Capability sets as provided by CAIS (e.g.; user, job, 

project librarian) . 

At the object's subsystem, the following attributes may be associated with 
the object node and listed once each: 

Unique Object ID 

Type determining possible values and legal operations. 

Ownership 

Lock Management Information 
Priority Management Information 

Access History, a summary of on-line records plus archives. 

Multiple Copy References for distributed copies. 

Encryption Name, such as an algorithm or public key, if 

allowed. 

Sensitivity Labels for DoD mandatory access control. 

The unique ID may be composed of network entity ID, network. LAN ID, network 
cluster ID, cluster component ID, resource ID, processor ID, and time/date 
stamp. This is based on the premise that each single processor can create, 
at most, one object or one transaction during a time/date stamp period. For 
each possible subject, this would be listed once: 

User/User Class/Access ID 

The following may be listed as many times as necessary for each 
subject: 

Logical Reference, an alias permitted to the subject. 

Intent, which establishes access synchronization with users 
of a node. 
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Access Capability Requirement, necessary and resulting 
privileges provided in CAIS. 

Location Restriction, such as secure area requirements. 

Password, as required. 

Template Restriction allows access to only designated 
fields, records, or other subsets of the file. 

The CAIS node model 3hows that up to four instances of the last set of 
attributes may be needed. They are: 

1. The node itself. 

2. The attributes of the node. 

3. The relationships of the object node to other nodes. 

4. The attributes of the relationships. 

For instance, the subject may be able to copy the object but not be allowed 
to read the attributes. The subject may be allowed to know that an object 
exists but is not able to copy it (e.g., execute). 

General Requirements for a Dynamic Multilevel Security Prototype 

Support for access control should be physically located in the extended run 
time library (XRTL) and execute as privileged code under the control of a 
Mission and Safety Critical (MASC) Kernel. It should be developed in a 
modular fashion 30 that no more support than is needed is loaded into a 
target . 

Fault management should be offered in the XRTL. Data integrity must be 
preserved in spite of system failures. 

Access control and constraint checking must be maintained non-stop. 

Dynamic redefinition and selection of all data being transferred must also 
be verified. 

Security activities must be accomplished with no disruption of DMS services. 

Checkpoints are needed for fault tolerance. The mechanism for these must be 
secured in all flight safety critical systems. 

Deadlock detection and resolution are needed for fault tolerance. This 

mechanism should also be secured in all flight safety critical systems. 

Security of data must be maintained through out its entire life cycle. 

Security labels must be included with all transmitted data and transparent 
to the user. 
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Devices should be labeled and the label should include the physical 
location. 

Information and/or control messages for mission and safety critical 
components that are to be transmitted, mailed or otherwise subject to 
possible exposure must be encrypted. 

Space Station subsystems must operate autonomously. No more data than 
necessary must be exchanged. 

Some secure data mu3t be "invisible" to unauthorized subjects. The CAIS-A 
Model provides for such access control. 

All access activity (including failed attempts) must be monitored and an 
audit trail maintained. A decision is needed for each type of security as 
to how long this log must be archived and where it should be located. The 
CAIS Model provides paths for an audit trail. 

The User Interface (UI) Executive is charged with keeping track of which 
user is linked to which object and with routing messages or requests. This 
concept should be merged with the idea of object managers in the Clear Lake 
Model. 

The UI Language (UIL) Interpreter must validate UIL statements and that the 
user has access to objects. This should also be considered under the aspect 
of the object manager. 

User interface menus should not be displayed until the user has been 
verified and should only display options and objects which are currently 
legal to the user. 

A user profile data file, as identified in the DMS Specification, should 
exist in a secure location and contain his access authority information 
perhaps in an encrypted form. This information should not be duplicated 
outside of the profile. Passwords should be meaningless but pronounceable 
and created by the owner. 

User-created access controls must be confined to objects owned by that user. 
If ownership changes, the access controls must be re-created by the new 
owner . 

Automatic backup and recovery is not supported by the software installation 
system. Restart conventions, including manual identification of a safe 
backup point, must be through controlled access. 

The DMS shall dynamically manage the redundancy of the DMS network services 
and resources and automatically reconfigure for fault tolerance. The same 
access control that existed before the fault must be maintained. Changes in 
access control data that may have been made during the recovery process must 
be dynamically monitored and installed in the reconfigured system. 

The security level of any part of the system must be dynamically adjustable 
within the multilevel security definition at run time. 

Binding of appropriate resources must be dynamically adjustable at run time. 



The entire system or any part must be dynamically extensible at run time. 

A transaction (T) or subtransaction (S) is the smallest group of actions 
that can be considered as a unit . Each will succeed or fail as one unit . 
The system must be capable of managing distributed, nested transactions 
which support: 

parallel execution of Ts and Ss 
recovery at the T or S level. 

For each transaction or subtransaction, an application specified set of 
ordered recovery options will be supported. 


Each process in a state of execution must have its thread of control 
hierarchically accessible by the PCEE. Each process must be able to trace 
its ancestry to the root node of the program or query. Each must be able to 
identify and query its children processes . ' 

Services and resources of the system must be structured hierarchically and 
be sustained as stable interface sets. [14] All recovery procedures must be 
performed through these layers. Higher layers can recover from specified 
types of failure in lower layers. 

Procedures in individual system parts must be capable of calling or sending 
messages to each other remotely. Some messages require the semantics of 
"send, no wait". Some messages require the semantics of "remote procedure 
call' with a specified approach to orphans and other faults. the third set 
of message requirements support the "rendevous” semantics. 

For each mission and/or safety critical application process which is 
eligible to be executed on some specified set of processing resources, 
behavioral predicates will be asserted which produce independent and timely 
health and status checks on the progress of the process. When progress is 
unacceptable because of problems involving the process, the processor, or 
the context of the execution environment, specified recovery actions will be 
initiated. 

Comparison of Requirements and Available Standards/Proposals 

The following table lists the recommended features of the proposed security 
prototype and sources of these requirements or available implementation 
guides. 


Prototype Requirements and Available Standards 


Requirement 


CL Model CAIS-A Orange Book DMS Spec. 


OSI 


Access history 

X 


X 

Agents 

X 



Audit trail 

X 

X 

X 


x 

x 


X 
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Requirement 


CL Model 


CAIS-A Orange Book QMS Spec. OS I 


Binding of resources 


(dynamic) x 

CAIS, OS I binding x 
Capability 

attributes x 

Checkpoints x 

Classify subject & 
object x 

Command/ request 


messages interop, x 
Compare subject, 
object attributes x 


Configuration Mgt. x 

Constraint check x 

Data display to 

authorized x 

Date, time stamp x 

Deadlock detection 
and resolution x 

Device Label x 

Discretionary 
access x 

Emergency mode fix 
Encryption name x 

Extensibility 

(dynamic) x 

Fault tolerance x 

Firewalling x 

Formal model 
Info/DB component 
interop . x 

Informal model 
Interface document, x 

Label export x 

Label integrity x 

Label output x 

Layered recovery x 

Mandatory Access x 

Monitor events x 

Multi -copy ref. x 

Multilevel security 
(dynamic) x 

Nested transactions 
(distributed) x 

Network security x 

Notify user 
Non-stop perform. x 

Object managers x 

Object type x 

Objects hierarchy x 


x 


X X 


X X 

X 
X 

X 

X. 


X X 

X X 


X 

X 

X 

X 

X 

X 

X 

X X 

X 

X X 

X 


X 


X 

X 

X X 

X X 


X 

X 


X 


X 

X 


X 

X 

X 


X 


X 

X 

X X 


X 

X 


X X 

X 

X 
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Requirement 


CL Model CAIS-A Orange Book DMS Spec. OSI 


Object reuse 
OSI communication x 
Override automatic 
systems 

Password x 

Periodic validation x 
Pools of processes 
and processors x 
Prioritized message x 
Protect mass stores x 
Protect TCB x 

Read up x 

Reconf igurat ion 

(dynamic) x 

Redundancy mgt. 

(dynamic) x 

Remote procedure 
call x 

Remote task 

rendevous x 

Restart conventions x 
Security adminis- x 
t rat or 

Send, no wait x 

Simulations x 

Single site image x 
Software (multi- 
version, fault 
tolerant) x 

Stable storage x 

Sys. documentation x 
Sys. monitor x 

TCB domain 
Template 

restriction x 

Threads of control 
(hierarchical) x 
Trusted path 
Unique device ID x 
Unique location ID x 
Unique subject, 
transaction, 
object IDs x 

User IF database x 
User IF executive 
User IF language 
interpreter 
User's manual x 

User's privacy 
mechanisms 

User profile x 


x 


X 

X 


X 

X 

X 


X 


X 


X 

X 


X 


X 

X 


X 


X X 

X 

X 


X X 

X 


X 


X 

X 


X 


X 


X 


X 

X 


X 

X 

X 

X 

X 

X 

X 
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Requirement CL Model CAIS-A Orange Book DMS Spec. OSI 

views restricted x x 
Write down x x 

Suggested Further Research and Resources 

The following are areas that require more study. An attempt is made to 
identify sources of information or possible prototypes. 

The Trusted Network Interpretation (TNI) is now available. This document 
must be consulted before the prototype is built. Jay Ferguson at the 
National Computer Security Center, NSA, has offered to advise us of the 
progress of this effort. 

A level B3 trusted computer base (TCB) requires a formal model of the 
security policy supported by the TCB. J.E. Heaney, PRC Government 
Information Systems, presented a selection criteria for their secure 
microcomputer network prototype. [7] None of the formal models studied 
supported a network security model, and one must be developed for the 
prototype . 

A packet switched network must provide a mechanism to encrypt data but not 
encrypt packet headers and trailers. One possibility is to encrypt the data 
before packetizing. 

Simulations will be needed to test the security prototype and the final 
security system. 

A binding is needed between the OSI Communication Model and CAIS-A. The 
CAIS-A design team has stated that communication and network management is 
beyond the scope of the CAIS-A Model. 

The Clear Lake Model of a NOS calls for rendevous of remote tasks, remote 
procedure calls and "sends with no waits." A standard must be defined for 
the granularity of security among job, process and task and a means to 
enforce the security policy. 

A way must be found to verify the location of a subject. Clearance might 
depend on the surroundings. Small portable devices are a challenge for 
location labels. How can the label be verified every time the device is 
moved? 

A complete security chain consists of accountability, prevention, detection 
and enforcement. All of these can be mostly accomplished with software, but 
eventually administration is needed. A prototype plan must include 
documented administration rules and procedures. 

A dynamic multilevel security model is one of twelve components proposed 
for a system interface set of a Portable Common Execution Environment (PCEE) 
to provide the proper both mission and safety requirements fulfillment for 
the Space Station. The other eleven components are required for a prototype 
that would completely prove security as an important aspect of safety. They 
are listed below: 
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Interface features and options for a tailorable run time 
support environment. 

Software structures which facilitate firewalling, layered 
recovery capabilities, dynamic reconfiguration and 
extensibility for fault tolerance. 

Pools of processes and processors capable of non-stop 

operation in a fault tolerant programming environment. 

A multiversion, fault tolerant programming capability. 

Command language interface between the SISs of the 
integration and target environment's PCEE. 

System-wide like-cycle-unique identification and history of 
all subjects, objects and transactions. 

Dynamic, multilevel security in the target and integration 

environments (B3 class integrity requirements and beyond) . 

A message interface supporting communication among clusters. 

Hierarchical run time structure of the threads of control of 
each program. 

A redundancy management subsystem for safety critical 
services and resources. 

A stable storage subsystem for each cluster. 

A management subsystem for distributed, nested transactions. 

Summary 

Safety for the Space Station necessitates security and many more elements. 
A means must be found to provide automatic, quick decisions on who or what 
is allowed access to flight safety critical applications. 





REQUIREMENTS AND ESTIMATE FOR A 
PROTOTYPE MULTILEVEL SECURE SYSTEM 

A minimal configuration for a proof of concept for an end-to-end multilevel 
secure system for the major entities of the Space Station Program must be 
capable of simultaneously supporting the following demonstrations of 
multilevel security enforcement under a variety of work load scenarios: 

within the processing of each participating processor, 
within the processing of each cluster of parallel processors 
interconnected by shared memory or shared bus, 
within the processing of each local area network (LAN) with 
clusters interconnected by a serial communication media, 
within the processing of a wide area network (WAN) which 

integrates physically separate LANs in to an end-to-end system. 

A fully instrumented, highly reconfigurable test bed for the target 
environment is proposed to facilitate this investigation and development. 
It will include programs to provide access control management needed to 
support the integrity of mission and safety critical components for Orange 
Book level B3 and below. It will rely on the existing network, database and 
applications management routines in the prototype systems. 

The test bed is described by the items below: 

1. To achieve this demonstration capability, a minimum configuration is 
needed to support: 

Three LANs interconnected by a WAN 
Three clusters per LAN 

Three processors and associated resources per cluster 

2. Specified procedures and guidelines shall permit additions of LANs, 
clusters per LAN and/or processors per cluster which shall not require: 

The system to be stopped. 

The operating system to be changed, or 

The integrity of the multilevel security (MLS) system to be 
compromised. 

3. Different clusters may be implemented with different instruction 
set architectures without loss of: 

Binary level interoperability. 

Source level transportability, or 
MLS integrity among the clusters. 

4. Different clusters may have differing perceptions of time without 
compromising the system MLS support for mission and safety critical 
components. 

5. Both objects and transactions may migrate among specified clusters 
in the LANs and the WAN without compromising the integrity of the 

MLS system. 
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6. Both objects and transactions may be replaced among specified clusters 
in LANs and the WAN without compromising the integrity of the MLS 
system. 

Advanced development is required in order to implement the test bed. A 
minimum team of four full time, top-level engineers for a period of six 
years is needed to provide the input for building the dynamic MLS portion of 
the test bed and integrating it to the other eleven components. A 
recommended schedule is to pursue the advanced development of the above 
items in three phases: 

Phase 1 Items 1 and 2 Years 1 and 2 

Phase 2 Items 3 and 4 Years 3 and 4 

Phase 3 Items 5 and 6 Years 5 and $ 
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GLOSSARY 


AJPO 

ANSI 

APSE 

CAIS 

DOD 

ISO 

ID 

JSC 

KAPSE 

KIT 

MLS 

NASA 

NOS 

NOSC 

Orange 

Book 

OS I 

SERC 

' TCB 

TNI 

UH-CL 

WG 


Ada Joint Programming Office, U.S. Department of Defense 

American National Standards Institute 

Ada Program Support Environment 

Common APSE Interface Set 

Department of Defense 

International Standards Organization 

Identification 

Johnson Space Center 

Kernel Ada Programming Support Environment 
KAPSE Interface Team 
Multilevel Security 

National Aeronautics & Space Administration 
Network Operating System 
Naval Ocean Systems Center 

Trusted Computer System Evaluation Criteria 
Open Systems Interconnection 
Software Engineering Research Center 
Trusted Computer Base 
Trusted Network Interpretation 
University of Houston at Clear Lake 
Working Group 
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APPENDIX A 


ACCESS CONTROL FOR A SAFETY CRITICAL 
DISTRIBUTED SYSTEM INTERFACE SET 
Sue ueCrand 
SofTech, Houston 


The Space Station Program (SSP) requires a system that has many 
safety critical resources that must be kept secure. The Space 
Station Information System (SSIS) is defined as the integrated 
set of space and ground data and information networks which 
provide required data and information services to the flight 
crew, ground operations personnel, and the customer community. 

It includes as its elements not only flight element systems such 
as the onboard data management, communications and tracking 
systems; but also existing and planned institutional systems such 
as the NASACommunicacions System (NASCOM), the Tracking and Data 
Relay Satellite System (TDRSS) and che data and communications 
networks of the scientific and industrial users and che 
international partners. The SSIS is conceived to support che 
full range of users in all operations of their subsystems or 
experiments that involve data handling, processing and/or storage 
regardless of where each user is physically located. [18] 

Dr. Dana Hall, Acting Director, SSP Information Systems 
Management Division, says that a user may be a subsystem monitor 
(human or automated expert system) in a control system, graduate 
student at a university conducting a space located experiment, or 
a crewperson correcting a manufacturing process in consultation 
with someone in che ground home factory. Through all of these 
activities on this large, complex, non-scop distributed system, 
the safety critical components must be secure. This paper will 
discuss the access control of these components and how this fits 
into a plan by che Software Engineering Research Center (SERC) 
for developing computer system interface secs (SISs) for these 
sys terns . 

Space Station Safety 

The Tri-Service Software Systems Safety Working Group composed 
che following definition: [3] 

Software systems safety is che optimization of systems 
safety in the design, development, use and maintenance 
of software systems and their integration with safety 
critical hardware systems in an operational 
envi ronmen c . 

Safety critical computer software components are defined as 
computer software components (processes, functions, values or 
program states) whose Inadvertent occurrence, failure to occur 
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when required, occurrence ouc o£ sequence, occurrence in 
combination with ocher functions or erroneous value can result in 
a hazard or Loss of resource predictability or control. 

Software can be used in the following ways to safely control a 
system: 

Autonomous control 

Control of potentially hazardous hardware or system 
components 

Management of Information requiring immediate operator 
action 

v 

Management of information with which an operator or another 
system makes critical decisions 

The Space Station is one of the most complex systems yet 
undertaken. This increases the risk of a combination of faults 
that individually may not be a problem, but combined can cause a 
serious threat. Safety planning must be Incorporated into the 
system development effort from the beginning. This allows 
technical safety mechanisms to complement and augment rather chan 
supplant the system design. 

Space Station Access Control 

An integral part of this Space Station system safety is access 
control of critical components. It must be considered from the 
very beginning of the system lifecycle and planned to be 
controlled in the domain of a security staff and a trusted 
computer system. Space Station systems may be characterized In 
the following ways: 

Parallel processing within a cluster attached to a local 
area network (LAN). 

Distributed and paralleL processing among groups of LANs. 
Distributed and parallel processing among wide area networks 
(WANs) of Integrated LANs and clusters. 

All access granted to users must be monitored and controlled for 
the appropriate operations, resources and time slices. Access to 
safety and mission critical components of the Space Station 
should never be available at any time In the lifecycle to the 
hacker who inadvertently causes damage, the terrorist who 
maliciously seeks to cause destruction, or a disgruntled former 
staff member who leaves with potentially dangerous knowledge. 

A special multi-level security model must be developed and 
prototyped chat will fulfill the spectrum of safety requirements 
of the entire Space Station system and still permit the 
fulfillment of the mission requirements of its ground, on-orbit 
and co-orbit subsystems. 
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The Software Engineering Research Center (SERC) Model 

In 1986 Ada* was designated as che computer language of choice 
for the Space Station Program (SSP). This was after 
recommendations of the ADa Programming Support Environment (APSE) 
Beta Test Team. This team composed of members from NASA/Johnson 
Space Center (JSC), University of Houston - Clear Lake (UH-CL) 
and over 30 participating NASA contractors concurred that Ada was 
the most appropriate language for the SSP system development and 
support. This support is expected to be over distributed, 
heterogeneous host and carget systems, will evolve over a 30 year 
period and have an indefinite life cycle. Ada was designed to 
provide reduced cost primarily through portability of tools, 
software and programmers. From this APSE Beta Test Team effort 
grew the Software Engineering Research Center (SERC). It is 
located at University of Houston - Clear Lake and sponsored by 
NASA. Dr. Charles McKay is Technical Director. 

In response to the strong commitment of NASA to the lifecycle 
support of safety of life and property, a SERC team has proposed 
a Clear Lake Model for Computer Systems and Software Safety in a 
Portable Common Execution Environment (PCEE). This model is 
built using the Ada computer language and is meant to provide the 
following : 

A baseline from which subsequent progress in the appropriate 
environments may be made. 

An extensible or corapac table model which will improve safety 
in larger, more complex or smaller, more simple 
applications . 

A "lessons implied/ learned" stimulus and opportunity to 

develop methodologies and^ tools which better address 
the lifecycle issues of safety. [14] 

SSP Computer Environments 

The SERC team reports that the SSP requires three distinct 
environments and associated activities. They are: 

A host environment where software for the target environment 
is developed and sustained. 

A target environment where che executable versions of che 

software developed in the host environment are deployed 
and operated. 

An integration environment where the configuration of che 
current target environment baseline is controlled. 

Functional requirements such as productivity and phase management 
are che primary drivers in the host environment. Target 
environments are strongly influenced by non— functional 
requirements such as real time, fault tolerance, power and 
capacity constraints. 


*Ada is che registered trademark of che US Government (AJPO). 
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The integration environment has been added to che traditional 
approach in order to facilitate scaling up of small models and 
creating more complex models from proven building blocks. This 
environment is the domain of those responsible for the test and 
integration plans used to interactively advance the target 
environment baseline with approved changes in software emanating 
from the host environments. It is used to prove that safety and 
security are considered in each component at all times. This 
environment is also used for controlling interactions with the 
target environment to maximize safety during emergencies. 

Static and Dynamic Viewpoints 

Two macroscopic perspectives are useful for understanding the 
requirements of the SSP environments. The first is the static 
viewpoint thac encompasses all host environment system and 
software phases- of development and support. 

The second perspective is a dynamic viewpoint of program 
execution and crosses all three environments during all 
development and support phases. It considers such issues as che 
ability to sustain safety while fulfilling mission requirements. 
Related to this issue is the ability to assure access control of 
all safety critical components. 

Space STation System Interface Sets 

All three SSP environments have requirements for User Interface 
Sets (UISs) for human-system interface and System Interface Secs 
(SISs) for che interfaces of the application software and command 
language to che underlying system software and hardware 
resources. The SERC team effort concentrates on the SISs. The 
goal is to allow such things as tools, rules, application 
software, test software and command language scripts to be 
developed, acquired and supported on a foundation of virtual 
interface specifications. This fulfills the SSP requirement of 
avoiding dependence on the physical interface specifications of a 
particular operating system, data management system, 
communication system or instruction set architecture. 

Two aids in fulfilling these requirements are the use of Encicy 
Ac t r i bu c e /R e 1 a t i onsh ip Attribute (EA/RA) models and the concept 
of SISs. An EA/RA model is one that represents domains of 
interest in: 

The objects within each domain 
Relevant attributes of these objects 
Relationships among che objects 
Relevant attributes of these relationships. 


The objeccs may be either passive (e.g. daca objects with no 
thread of execution of their own) or active (i.e. possess their 
own thread of execution). Further more the relationships are- 
context sensitive (i.e. "normal" processing vs. "exception" 
processing) and may be between or among: 

Active objects to active objeccs. 

Active objects to passive objeccs. 

Passive objects to passive objects. 

An EA/RA model which is available on-line in the execution 
environment can be an enormous aid in controlling access between 
and among such objects. The draft International Standards 
Organization (ISO) standard, Information Resource Dictionary 
System (IRDS) is being studied by the SERC team for this 
purpose. [23] This standard defines means to: 

Document the environment 
Maintain an Inventory of Components 
Provide a model of the environment 

Support the operational aspects of the environment 
Illustrate the interrelationship of components 
Document the phy s i c al / logica 1 location of components. 

An overall stability for the SISs is obtained by fulfilling three 
requirements. First, from the perspective of an all-encompassing 
SIS is a virtual interface set resulting from the union of all 
abstract specif lcaeloas of the objects designed to be visible at 
this interface. 

Second, from the perspective of any given object within a 
particular SIS, there should be a formal model in the EA/RA form 
for the proper visibility among all objects and a grouping of 
objects into discreet sets with associated services and classes 
of services. 

Third, from the perspective of external objects outside each SIS, 
a formal model in EA/RA form is needed to describe external 
interfaces to services and access control of services and 
resources. 

A Common APSE Interface Set (CAIS) has been defined to describe 
the interface in a host environment of all Ada development tools 
and all operating systems available to each host. The SERC team 
recommends the adoption of the CAIS as an extensible baseline for 
the SIS of the host and integration environments. It reflects 
only the static viewpoint of tool builders and administrators, 
but it is an excellent beginning and fits in as a subset of the 
overall SIS. 
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A Portable Common Execution Environment 

Throughout the iterative, dynamic evolutionary life cycle of each 
system of the SSP, the software in various forms, versions or 
representations will reside and migrate among the three computer 
environments. A portable common execution environment (PCEE) is 
needed for a solution to the challenge of productivity and 
support of systems requirements and safety. The proper PCEE 
model will facilitate the management of the life cycle complexity 
of software systems in a similar manner across all three 
environments. 

Each unit would have a version of the PCEE that is a stable 
interface set described by Ada packages selected from a common 
run time library. The Ada language has this package structure to 
provide modularity for just this kind of application. A PCEE is 
defined to consist of: 

A set of policies for the management of services and 
resources to be provided to the application programs, 
The set of management modules to enforce the policies, and 
A set of rules for modification and extension. 

The framework of the entire PCEE must be flexible enough to be 
represented in a number of ways in order to accommodate tailoring 
and extension in a large number of implementations. The PCEE 
must also support the differing operational requirements of the 
three environments. It should hide underlying system software 
implementations ranging from a tailorable bare operation in a 
target to a tailorable operating system in a host to a general 
purpose run time system that is a combination of the first two 
envi ronmencs . 

It is the goal of the SERC team that the PCEE support the 
following assertion in regards to safety: 

If safety Is adequately addressed in the host environments 
throughout development and acquisition 
then the support of this explicitly addressed sec of safety 
specifications will be dependent upon a run time 
environment built to: 

Monitor the system and detect faults that enter the 
system state vectors as soon as possible. 

Firewall their propagation 
Analyze their effects 
Recover safely. [14] 

Each run time environment must be secured in order to assure that 
the above will always be available. This run time assertion is 
dependent upon secure and safe context sensitive access control. 

The SERC team has produced the "Clear Lake Model for Life Cycle 
Support of Computer Systems and Software Safety In the Target and 
Integration Environments of the Space Station Program". [14] 
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The effort began by studying the safety issues and the models, 
mechods and cools currently purported co address these Issues. 
From chis study Che ceara identified requirements for a "safety 
kernel" of key components of an execution environment underlying 
a P C E E . 

Twelve highly interdependent models of key components in a System 
Inter-face Set of a PCEE are being investigated and/or developed. 
They are: 

Interface features and options for a tailorable run time 
support environment. 

Software structures which facilitate firewalling, layered 
recovery capabilities, dynamic reconfiguration and 
extensibility for fault tolerance. 

Pools of processes and processors capable of non-stop 
operation in a fault tolerant environment. 

A multiversion, fault tolerant programming capability. 
Command language interface between the SISs of the 
integration and target environments' PCEE. 

System-wide life-cycle-unique identification and history of 
all objects and transactions. 

Dynamic, multilevel security in the target and integration 
environments (B3 class integrity requirements and 
beyond ) 

A message interface supporting communication among clusters. 
Hierarchical run time structure of the threads of control of 
each program. 

A redundancy management subsystem for safety critical 
services and resources. 

A stable storage subsystem for each cluster. 

A management subsystem for distributed, nested transactions. 

All of the above component models are intended to reside in 
safety kernels which execute in privileged mode beneath the SIS 
of processors participating in the PCEE. Note also that the 
dynamic, multilevel security model is only one of the twelve 
components. In other words, security is a means to the end of 
simultaneously supporting both mission and safety requirements, 
rather than an end in itself. 

Space Staclon Security 

The security component of the PCEE is based on a model presented 
at the AIAA/ ACM/ NASA/ IEEE Computers in Aerospace V Conference in 
October, 1985. (10] It presented a "superset" of building blocks 

for enforcing multilevel security in a distributed target 
environment. It is based on subjects accessing objects. Both 
the subjects and objects have attributes, and the method involves 
a comparison of these attributes in a dynamically changing, 
heterogeneous distributed system. Subjects may be users via 
their active processes; and the objects may be data, devices and 
other processes. The system must not only meet immediate 
security requirements but must react to current capability 
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limicac Lons such as small memory space or dlf fersne processor 
speeds. The sofeware for this model is co be wrlccen in Ada, and 
che model complies vich che Orange Book, Open System 
I n c e r c o n ne c c i o n (OSI) and CAIS standards. 

Ada is especially suited co che needs of chls security model 
because ic is strongly cyped. [12] F.ach object named in a 
program has the traditional accribute of value (constant, 
variable) and also che attribute of type. The type attribute 
defines the kinds of values and operations allowed to be 
associated with che object. The Ada language requires thac all 
objeecs be cyped and enforces this requirement during 
compilation. If an untyped object is discovered or if che wrong 
value or operation is associated with che object, an error is 
reported. All must be in order before the program is executed. 
Any secure resource may be named as an object and only allowed 
operations associated with each one. 

The EA/RA structure of che PCEE can be used to passively 
represent a design structure depicting che relevant objects, 
their relationships and the key attributes that must be compared 
for access control. Each object embodies che sofeware 
engineering principles of abstraction, modularity, information 
hiding and localization needed for security enforcement. Further 
more the on-line use of EA/RA structures can be used actively by 
the PCEE processes to enforce safety and integrity constraints 
for access control in the execution environment. 

The SSP requires multilevel security of che Orange Book (Trusced 
Computer System Evaluation Criteria) Level 3 and below. This 
trusted computer base involves both discretionary and mandatory 
access control. Ic must satisfy che reference monitor 
requirements chat it mediate all access of subjects to objects, 
be tamperproof, and be small enough to be subjected to analysis 
and tests. A security administrator is supported, audit 
mechanisms are expanded to signal security - relevant events and 
system recovery procedures are required. 

The Puce Book (Trusced Network Evaluation Criceria) is expected 
co offer guidelines applicable to che PCEE model when it is 
available. [6] 

The Open Systems Interconnection (OSI) Model provides standards 
for the exchange of information among systems chat are "open" co 
anocher for this purpose by virtue of their mucual use of che 
applicable standards. A system is defined in this international 
standard as it is in che PCEE Model. (9] 

The purpose of che OSI is co define a sec of standards to enable 
open systems to communicate and cooperate. It uses a layered 
architecture for operations such as intersystem connections, 
transmission data and error functions. This model is mandated 
for che design of a network operating system for the SSP. 
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Proposed Prototype 


Before proposing a security prototype effort, a study was made of 
the above standards, the S ER C PCEE model and the SSP 
specifications for a Data Management System (DMS). Careful note 
was made of DMS requirements that had securtcy implications, 
especially in safety critical components. Some of these 
requirements are: 

Override capability of automatic systems is required for 
authorized onboard and ground crews. 

A User Interface Executive must keep crack of which user is 
linked to which application tool. 

Authorized emergency priority messages must be forwarded. 
Command differentiation is to be suitable for managing 

operations and to protec cc he system from inadvertent 
and unauthorized payload operations. 

Local and remote access to onboard DMS databases must be 
consistent with security and privacy practices. 

To facilitate research for a multilevel secure system for the 
Space Station, a minimal configuration for proof of concept for a 
reconf igurable testbed is proposed to NASA. It has the following 
characteristics and capabilities : 

There will be a minimum of 3 local area networks (LANs), each 
consisting of at least 3 clusters of processors. The LANs will 
be geographically separated and communicate over a wide area 
network (WAN) that is OSI compatible. 

In each cluster in each LAN there will be at least three 
processors, all of which can cooperate in parallel processing 
within the cluster. 

There will be the capability of distributed, parallel processing 
among the groups of LANs. 

There will be the capability of distributed, parallel processing 
among che LANs in the wide area network (WAN). 

A single, unified network operating system will be the sura of the 
individual run time support environments in the clusters. It 
will provide the following for che prototype: _ ir . 

A set of policies for che management of services and 

resources to be provided to che application programs. 
The set of management modules to enforce che policies. 

A set of rules for modification and extension. 

This network will be able to support multiprogramming wichln and 
among multiprocessors. That is, one processor will be able to 
simultaneously handle more than one program and one program will 
be able to be executed with more than one processor. Also, there 
will be che capability to have multitasking within a program and 
across multiple programs and processors. 
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Each cliiscer will be built upon che twelve components of the SIS 
of che Clear Lake Model for a PCEE and will consist of a sec of 
components from these four classes: 

Processors with shared access to memory subsystems 
Memory subsystem with stable and volatile storage 
Communication links to other clusters 
Sharable services and resources* 

There will be a common sense of timing throughout the WAN* That 
is, each system may have its own timing mechanism and 
granularity, but it must be able to interpret time stamps from 
the other systems. 

A PCEE written in Ada will be the only environment type used in 
che development- of each component of each cluster. No untyped 
language may be accessible to provide a crap door to the 
operating system, hardware or ocher safety critical resources. 
Hardware representation specifications will be restricted to 
chose individually approved and monitored by the security 
adminls t racor . 

In order to control access to saf ety critical components, each 
node will have only a PCEE-complianc operating system and access 
only to PCEE-complianc tools. All user interfaces will be 
through the PCEE only. 

Code will be written in Ada to demonstrate the scenarios in the 
paper entitled ’’Access Control Model for a Distributed, CAIS- 
Conforming System". It will include access control attributes 
for each entity and appropriate relationship in che system. It 
will include programs to provide access control management for 
Orange Book level B3 and beyond. It will rely on the existing 
network, database and applications management routines in che 
prototype systems. 

Summary 

The Clear Lake Model for a System Interface Sec of a Portable 
Common Execution Environment is believed to fulfill the 
requirements for System Interface Secs that protect che safety of 
critical components of the Space Station orbiting, coorbiting and 
ground systems and the interaction of these systems while 
simultaneously supporting mission requirements. A dynamic, 
multilevel security model has been designed as a part of the PCEE 
to assure access control of these safety critical components as 
well as privacy for scientific or user-proprietary data. A 
prototype of che PCEE model has been proposed to NASA in order to 
prove the concepts presented here. 
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